JavaScript による図形制御「バク転＋伸身宙返り」（もう一度）

web6047　2020年 10月

プログラミングやRPG（作るほう）が好きな人の日記

このホームページは毎日 夜11時にアクセスできなくなります。 朝6時半に再開されます。（世の中のネット依存対策として） 例外でアクセスができる場合があります。上のメニューの「aboutThisWebsite」を参照してください。 URL は https でもアクセスできます。 黒猫画像はクリック（タッチ）すると消えます。 NO PC WEEK とは私自身の健康のために私のパソコンの使用を制限する期間です。 【【 私自身へ、記事の先頭に5W1H を書くといいかも 】】

NO PC WEEK に代わる PC 使用制限のしくみ（β版）

No.	A.（ついでに 勉強1問）	B. PC使用 開始時刻	C. 予定使用時間 時間:分 （当日限度時間 時間:分）	D. 予定終了時刻	E. 実際終了時刻	F. 実際使用時間 時間:分 （当日限度時間 時間:分） オーバー理由	G. 判定	H. 作業内容
221	◎	21:20	2:00（4:00）	23:20	2:30	3:10（2:00） 4連休で 気持ちが甘くなったのと 凝ってしまった	×	10月扉スクリプト
220	◎	16:20	2:00（4:00）	18:20	18:53	2:33（2:00） なかなかできなかった	×	10月扉スクリプト
219	◎	18:55	1:30（1:30）	20:25	20:45	1:50（1:30）	△	10月扉スクリプト
218	◎	19:50	1:30（1:30）	21:20	21:40	1:50（1:30）	△	10月扉スクリプト
217	◎	20:10	1:00（3:00）	21:10	21:27	1:17（3:00）	○	10月扉スクリプト
216	◎	13:40	1:00（3:00）	14:40	14:54	1:14（3:00）	○	10月扉スクリプト
215	×	23:00	1:00（4:00）	24:00	1:10	2:10（4:00） 記事は時間がかかるな…	×	ガンプラ記事
214	◎	20:30	1:00（4:00）	21:30	21:41	1:11（4:00）	○	10月扉スクリプト
213	◎	18:00	1:00（4:00）	19:00	19:10	1:10（4:00）	○	10月扉スクリプト
212	◎	16:15	1:00（4:00）	17:15	17:19	1:04（4:00）	◎	10月扉スクリプト
211	◎	22:30	1:30（3:00）	0:00	0:20	1:50（3:00）	△	10月扉スクリプト
210	◎	19:00	1:30（3:00）	20:30	20:32	1:32（3:00）	◎	10月扉スクリプト
209	◎	18:55	1:30（1:30）	20:25	20:37	1:42（1:30）	○	10月扉スクリプト
×、△、"記録しなかった長時間作業" が多いので、NO PC WEEK 1週間実施（10/20（火）まで）
208	×	14:20	1:30（3:00）	15:50	15:50	1:30（3:00）	◎	自作DRAM回路
207	×	21:50	1:00（2:00）	22:50	24:20	2:30（2:00） 同じく、解明したく	×	自作DRAM回路
206	◎	16:55	1:00（2:00）	17:55	19：15	1:20（2:00）	△	自作DRAM回路
記録しなかった長時間作業あり　作業内容：記事作成
205	◎	19:00	2:00（2:00）	21:00	21:33	2:31（2:00） 解明したかった	×	自作DRAM回路
記録しなかった長時間作業あり　作業内容：キャラクター画像2点
204	◎	23:30	1:30（1:30）	1:00	1:19	1:49（1:30）	○	自作DRAM回路
203	◎	19:20	1:30（1:30）	20:50	21:27	2:07	× キリが悪かった…	自作DRAM回路
202	◎	23:05	1:00（1:00）	24:05	24:31	1:26（1:00）	△	自作DRAM回路
201	◎	21:50	2:00（3:00）	23:50	23:46	1:56（3:00）	◎	自作DRAM回路
200	◎	16:35	1:00（3:00）	17:35	17:54	1:19（3:00）	○	自作DRAM回路
記録しなかった長時間作業あり　作業内容：自作DRAM回路　調べもの
199	◎	17:45	1:30（4:00）	19:15	19:38	1:53（4:00）	△	自作DRAM回路
198	◎	13:10	1:30（4:00）	14:40	15:03	1:53（4:00）	△	自作DRAM回路

この表の意図：

多くの人はパソコンのやりすぎやネットゲームのやりすぎには困っていると思います。

参考に言うと、この表を使う前の私は 1 回の PC 使用時間がノンストップで 17 時間というときもあったし、平均で言うと毎日 9 時間はやっていたと思います。

そういう徹夜とか長時間作業をするよりも、昼間の短時間作業のほうが生産性は高いのでは？　と数年前から考えてきました。

パソコンの使用時間を事前に決めて、ネット上に公開することで、パソコンのやりすぎを防止できるかどうかこの表を使って試しています。

記入の法則：

• 日付は表示していません（私の生活パターンをすべて知らせるのはよくないから）。しかし、白と灰色の色分けは、同じ色の連続で同じ日を表しています。
• 左端の「A. （ついでに勉強1問）」について
  この表の目的とは異なりますが、ついでとして、遊び１００％の毎日を送るときでも勉強の習慣を忘れないために、たった1問で良いので解くことにします。
  正直言うと毎回遊ぶ前に必ず1問勉強するのは心が折れそうです。でも慣れさえすれば…と思います。追記：やってみると結構効果的で役立っています。
  行ったら◎、行わなかったら×　を記入。
• 右端の「G. 判定」について
  「D. 予定終了時刻」と「E. 実際終了時刻」を比べて、オーバーした時間によって判定を行う。
  ◎　9分以下
  ○　10分～19分
  △　20分～29分
  ×　30分以上　（オーバー理由を記載する）
• 平日の 1.5h、2.0h の PC 使用の連続が負担になっているので、「平日の PC 使用は月水金のみ、各日 1.5h まで」とする。火木で PC 使用しないことでうまいぐあいに「体力回復」されて、「生活」がうまく回り、プログラミング以外の「創作活動」（イラスト等）に時間が取れることを期待する。
• ×、△、"記録しなかった長時間作業" が多いと思ったら、NO PC WEEK を1週間実施する。
  ×、△、"記録しなかった長時間作業" は、「ちょっと必要だ」という気持ちでそうなったと思うので、悪いことではない。
  ただそのままだとこの表の意味がないので、NO PC WEEK の実施でバランスを取る。
  NO PC WEEK のあいだにもPCを使わなくてもやりたいことはいっぱいあるので問題ないだろう。

例外事項：

• 「E. 実際終了時刻」のあと、プログラミングの場合のみスッパリ終了しないで、今後のプログラミングの方針をテキストファイルに書くのは OK にしています。

廃止事項：

以下の事項は実施できないので廃止する。

• 自分のホームページやプログラムを読んでいて誤字脱字を発見した際、その「修正」は訪問者にとっても管理人にとっても有益なので、「タイマーで測って10分未満。1点修正したら終了」を条件に作業してよい。また、基本的にそれを連続させないこと。

中途結果：

結構いい結果になっています。炊事や掃除、散歩、早起きなどが好ましいリズムでできるようになりました。

（2020年9月6日追記：散歩、早起きは最近あまりできていません。掃除や炊事は理想的にできています）

また、パソコン以外の趣味も進むようになりました。電子回路、ガンプラ、RPG のプログラム以外のモンスターイラストやストーリーなど RPG の肉付け部分の創作、勉強、昔好きだったペーパークラフト等々。

そしてパソコンの趣味自体も深夜遅くまで行うよりも質が高くなったように感じます。制限された短い時間の中で結果を得ようとするので、取捨選択が行われているし、時間が終了して、空いた時間ができ、それがほどよい休憩になり、今後の作業の方針を落ち着いて検討することもできます。それが質につながっているのかなと思います。

この取り組みが、15 才 ～ 18 才くらいまでの高専（中退）に所属していた時に実施できていたら良かっただろうなと思います。でもそれくらいの年齢では経験が浅く、このような効果的なルール作りを行うことはできなかったと思います。自分は人に比べて「創作意欲」や「ゲームで遊ぶ欲望」におぼれやすいところがあり、そのコントロールはとても難しいです。

ちなみに、分単位で記録を取ったりして、だいぶマメに見えるかもしれませんが、Windows の日本語入力（MS-IME）で「いま」と入力し、 変換 キーを押さずに ↑ ボタンを押すと現在の時刻になります。道具の便利さが人をマメに見せるのかもしれません。

自分の家族にすすめたい：

パソコンのやりすぎやネットゲームのやりすぎは社会問題にもなっているので、そう思うご家族の方は多くいらっしゃると思います。私の両親も過去に私について問題にしていました。

この表はその家族が困っていたときから 30 年後に、私が自分で必要を感じて作ったものです。

私は今 一人暮らしをしていて、自分で生計を立てる中、パソコンにおぼれた生活をすると、生活がうまく回らなくなるんです。具体的には、

• 人前で疲れた顔を見せてしまい、人間関係がうまくいかなくなる。もっと具体的には、職場、とこや、お店のレジ、歯医者。
• 掃除、洗濯、炊事が後回しになり、実質、それらを行う時間がなくなってしまう。深夜遅くや翌日に回したり、行わなかったりする。

このような必要にせまられて自分の動機で始めた場合と、人からすすめられて始めた場合とでは、結果が異なると思います。

自分の切実な動機で始めたならうまくいくと思いますが、外から押し付けられたものはなかなか定着しないものです。

あまり適当なことは言えませんが、上記の青い部分で書いたことは、本人にとって得になることなので、「ときどき休憩して、他のあの趣味やってみたらどうだ？」とか「ときどき休憩したほうがプログラミングの質が上がるって話だぞ？」という形ですすめてみたらどうでしょうか。（それでも最終的には自立してもらうことは必要だと思いますが）

私が両親を困らせていたとき _(A) に、突然、外へ一人で出て行って、一人暮らしを始めたり、接客業を始めたり、いくつか資格取得したりといろいろ行えた理由というのは、正直言ってわかりません。（※途中で失業して2度、実家に戻ったことがあります。1 回目は 21 才くらいのときに 5 年、2 回目は 35 才くらいのときに1年未満、実家にいて、何もしてなかったり働いたりしていました）

私が両親を困らせていたのは 16 才 ~ 20 才くらいのころ _(上記A) ですが、そのころ家族と私自身と友人たちがみんなそれぞれ、私の生活について心配したり困ったり悩んだり、あの手この手を試したりしていました。そういう煮詰まったような状況が運命をそのように（解決の方向へ）動かすのかもしれません。運命がどうの というのは変ですが、そのくらいのことしか言えません。

この社会問題はクリアーすべきものみたいです。

2020/10/31（土）

10月扉スクリプト 作成経過 その５ -[svc]

ポーズを増やして、「バク転＋宙返り」になりました。

（器械体操を知っている人は「宙返り」の部分が、「宙返り」なのか「伸身宙返り」なのかどっちなんだと思うかもしれません）

2020/10/26（月）

10月扉スクリプト 作成経過 その４ -[svc]

▼その実行結果（JavaScript + CANVAS）

There is no canvas.
PROGRAM LIST

バク転ができるようになりました。

（でも、短い時間の中で結果を求めて、プログラムはグシャグシャになりました）

2020/10/25（日）

10月扉スクリプト 作成経過 その３ -[svc]

▼その実行結果（JavaScript + CANVAS）

There is no canvas.
PROGRAM LIST

地上に足をつけたり、手をつけたり。

2020/10/24（土）

ガンプラ「RG νガンダム」 -[plamo]

まだシール（デカール）を貼っていませんが、完成したので写真撮影！（ヒザの改造で不具合はありますが）

▼無料素材の地球画像で、「無料ジオラマ」！

※画像の太陽光と、ガンプラが部屋の照明で逆光になって効果的な写真になったのは、意図せず、まぐれです

■箱のポーズ
■そのアップ
■その正面
大河原邦夫氏のデザインを思わせる顔立ち
■パッケージ側面　”カラーパーツでボディの各部の濃淡まで再現”
■陸戦型ガンダムが可愛らしく見える
■ガンダムONEYEARWAR
のポーズで。

▼ファンネル台座がないので、あまったランナーで「根性ジオラマ」！

―――ガンプラ最初の発売1980年から2020年現在まで40年。

バンダイの模型技術の集大成とも言われる「RG νガンダム」。

このキットは、組み立て完成後、あまりのディテールの良さに 大人が思わず童心に戻ってしまう逸品だ―――

組み立て中に思ったこと：

ガンプラは完成後に楽しいばかりでなく、組み立て中にもドラマ（いろいろ感動する）があります。

説明書の工程タイトル	工程の番号表示	私が思ったこと
LEG UNITS （足部）	01-5　1コマ目 （内部フレームのふともも）	「やはりRGだ. 　　HGとはちがう」
	01-5　2コマ目 （内部フレームのひざ）	「なるほど 　　ああ、この動き」
	01-8　3コマ目 （外装のふくらはぎ）	「確かにHGとはちがう」
	01-9　”右脚の可動” （右脚完成後の動作確認）	「この可動のしやすさは 　　だいぶ考えられているな」
WAIST UNIT （腰部）	03-5 （フロントアーマー）	「なるほど 　　いいね」
CHEST UNIT （胸部）	04-2　2コマ目 （内部フレームの胸部）	「いいね」
	04-4　1コマ目 （内部フレームの肩関節）	「いいね」
	04-4　2コマ目 （胸部外装）	「なるほど」
	04-5　2コマ目 （胸部ダクト下の装甲）	「なるほど」
	04-6　2コマ目 （コックピットのハッチ部の胸の可動）	「なんか 　　すごい動き方してる」
ARM UNIT （腕部）	05-3　"右腕の可動" （右腕完成後の動作確認）	「ガンプラでこの表現の高さは 　　見たことがない」
	07-1　[肩部の組立]　2コマ目 （肩アーマー）	「いいね」
HEAD UNIT （頭部）	08-2　2コマ目 （頭の角）	「このRGというのは 　　部品が小さいから 　　床に座って作るのが良い. 　　机だと飛んで落ちて 　　なくす」
BACKPACK （バックパック）	09-2 （バーニヤ可動部）	「なるほど」
	09-3 （バーニヤ可動部をバックパックへ取付）	「フッ」（良い意味で）
WEAPONS （武器）	11-2 （ニュー・ハイパー・バズーカ後部　マガジン部）	「結構手が込んでるかな？」 （バズーカ全体のこと）
	13　[シールドの組立]　1コマ目 （シールド裏面　ミサイル）	「なるほど」
	15-6 （フィンファンネル完成）	「なるほど 　　この "羽" は 　　イケてる」 「完成後、 　　大人が童心に 　　戻れる逸品. 　　ディテールの良さに 　　思わずウキウキしてしまう」

▼上の表の「私が思ったこと」は、全部私が組み立て中に説明書に記入した文面です

次のRGは「ジオング」だそうです。（来年1月発売だそうな）

（訪問者のどんなニーズと この記事がつながるか）

• ガンプラ「RG νガンダム」を見たい。
• 日記を読みたい。

2020/10/23（金）

先月紹介したガンプラ「RG νガンダム」のヒザの改造は× -[plamo]

先月、ガンプラ「RG νガンダム」のヒザ部の改造について記事を書きましたが、完成してみると、意図したとおりの可動域は満足できますが、不具合が発生するので、みなさんは参考にして実行しないでください。

完成してヒザを思い思いに曲げると、ヒザのシリンダーのオスメスが、簡単に外れてしまいます！

10月扉スクリプト 作成経過 その２ -[svc]

▼その実行結果（JavaScript + CANVAS）

There is no canvas.
PROGRAM LIST

パーツ同士の連結。

▼その実行結果２（JavaScript + CANVAS）

There is no canvas.
PROGRAM LIST

人型。

（訪問者のどんなニーズと この記事がつながるか）

• プログラムの話を聞きたい。
• 日記を読みたい。

中島みゆき -[spirit]

16才の学生の頃、家族から「お前はこれ聴いたほうがいいよ」と すすめられた歌手は「ミスターチルドレン」でした。

ところが私が のめりこんだのは180度くらい違って、「中島みゆき」でした。

たしか、「マイレボリューション」という曲を聞きたくて？、歌手を探して、探し当てたのが、まちがえて「中島みゆき」で、それが縁で聞き始めたという、そんな いきさつ だったと思います。（「マイレボリューション」は渡辺美里ですよね。二人ともちょっと似た顔をしているから間違えたのかな…）

ずっと聴き続けていたけど、30才なかばくらいで聴くのをやめて、10年以上聴いていませんでしたが、久しぶりに iTunes の中に入れてあった 76曲（6時間） をちょっと聞いてみました。

すると、学生の頃は聞き流していた曲も、なんか歌詞を聞いていると、ちょっと涙腺がゆるむ。

たとえば、「ひとり」という曲の、「ねぇ、出会いの言葉を、忘れないでいてね。誰かにほめてもらったことなど、あれきりのことだもの」、「グッバイ、グッバイ、あしたからひとり、どんなさびしいときでも、頼れないのね」というフレーズ。べつに自分は似たような経験はしてないけど、４５歳という年齢でいろいろ経験したせいか、自然とわかってしまうような。

それだけではなく、どの曲も個性的であることに、あらためて気づきました。

研ナオコが言うには、中島みゆきという人の若いころは、「自分の髪型など気にせず、ノートに歌詞をひたすら書いている人」だったんだそうです。研ナオコがその姿を初めて見たとき「だれだ、このおばさんは！」と思ったとか。（いつかのラジオの中島みゆき特集で語っていました）

自分の力をとにかく磨きつづけるような人が、晩年に広く人気が出るんですかねぇ…。

いま若い人たちは、今聞いている曲や、観ている映画や、マンガ、小説など、大人になったらまた違うテイストで鑑賞できるので、今のうちに何も知らずに好んで鑑賞していると良いですよ。そのうち見えてきて楽しいです。

（訪問者のどんなニーズと この記事がつながるか）

• 日記を読みたい。

2020/10/21（水）

10月扉スクリプト 作成経過 その１ -[svc]

毎月、このウェブページの冒頭では、私が何かしらのプログラムを作って、ページの冒頭を飾っています。

今月は、私が以前から取り組んでいる「SVC」を 3D でやろうと思っています。

それはつまり、”3DCG制作で人物の姿勢を指示する骨組” である「ボーン」とまったく同じものです。

逆に言えば 3DCG のボーンを 2D で行っているものをわたしが個人的に「SVC」と名付けています。

SVC とは「サイドビューキャラクター」の頭文字を取ったものです。実際に動いている過去のサンプルはこれ

まずは 2D の状態で SVC のしくみをプログラムしています。（それだけでも大変なので11月いっぱいかかるとか…）

▼その実行結果（JavaScript + CANVAS）

There is no canvas.
PROGRAM LIST

やっぱりプログラミングは強烈にエンジンがかかるな…

（訪問者のどんなニーズと この記事がつながるか）

• プログラムの話を聞きたい。
• 日記を読みたい。

2020/10/10（土）

あれ？

キャラ↑を増やしたことについていろいろ思うこと

とっぴなキャラが突然現れて、いろいろな意味で戸惑うと思うので、どういうことなのかちょっと箇条書きで書こうと思います。

• キャラを単純に思い付いて（最初の動機）、ここに登場させたらどうかと思い、登場させて問題ないか検討した結果、大丈夫だと思って登場させました。
  真面目な電子回路、仕事として取り組んでいる情報工学、誰にでもできるわけではない聖域、または自分を引き立てる力として、そんなふうに電子回路や情報工学を見ている方は多いと思います。そのへんの方々が見たときにどう思うかとか、私個人のやり方とか、このサイトのターゲットが小中学生、高校生、一般の方と初心者の方であることなど、いろいろな思いがありますが、おおむね大丈夫かなと思いました。
• 実は女の子しか描けないのは私のポリシーに反しているんです。なので男が描けるのはうれしいです。
  女の子だけ↑の状態から、男が入り、バランスが取れる（現実味を帯びる）のではと これから期待しています。
  （「バランスのために男を登場させる」というのは今回においては2次的な動機（後から付けた動機）になっていますが、前々から考えていたことでもあります）
• 管理人対キャラ、またはキャラ同士の会話は、基本的に避けようと考えています。
  ただし、一方通行のコメントは行います。（たとえば私の書いた記事に対して「ダメじゃん！」と一言言ってそれで終わり、というもの）
  これまでもそうしてきました。
• 今回増やしたキャラの設定は、「思慮深く優しい、建設的、人を立てる」です。
  これはあくまでも設定であって、実際そうなるとは限りません。
  また、以前からいる 3Dお姉さん→  の設定は「キャリアウーマン」です。

「最初の動機」と「2次的な動機」について

「最初の動機」とか「2次的な動機」とか、ちょっとしたキャラ１つに対しておおげさに聞こえるかもしれませんが、そのへんをしっかり押さえないと、人間って駄目だと思うので。

RPG開発も同じで、最初の動機は「単なる、ファミコン版ドラゴンクエスト１へのあこがれ、追いかけ」なのであって、あとから出てきた「子供たちのために」という思いは、それは世間に認められやすく、ドラマチックで人の気を引きやすいので「”子供たちのために” 自分はRPGを作っている。私は倫理のリーダーだ」と勘違いしやすいですが、それは最初のもともとの動機ではないと自分にきちんと教えて間違えないようにします。最初の動機、つまり根っこの部分で本当に思っていることが「単なるあこがれ」（自分のためのもの）なのに、勘違いして「子供たちのために」と思ってしまうと、行動が裏腹になってしまい、失敗してしまいます。もちろん、最初は単なるあこがれで始めて、途中から「子供たちのために」と、根の部分で方針が取って代わるというのは問題ないと思います。

（世間を見ていると、自分の仕事の最初の動機（なんとなく成り行きで始めたとか）と2次的動機（愛は地球を救うの担い手とか）を、知らずに取り違えて失敗している人（特に有名人の人）がいて、自分もそうなりやすいほうだと思います。もし有名人の人で「愛は地球を救う」みたな仕事が来てしまったら、「自分の仕事じゃないけど、仕事だからやっとくか」程度にとらえれば間違えないかな…と思います。でも人々は「愛は地球を救う」について本気でやることを求めていて、適当～みたいな姿勢は好まないので、そういう仕事って難しいですねぇ。「実は自分のガラじゃないけど頑張って取り組みます」と一言公言してから始めるとか。それもダメなのかな～）

2020/10/9（金）

「自分たちで計画すると、何千倍も楽しくなる」

このサイトの方向性を、そういう方向へ変えていこうと思います。

絶好調～！赤丸急上昇～！死んだ☆（このところ、仕事内容の大変な他の現場でレギュラー2名のうち2名とも熱があると言って連日休んでいて、私がそのヘルプと自分の持ち場と両方やることになってしまい（そう言われたわけではないけど事実上そうなっている。上の人も悪気はない様子）私の体力がもう限界を超えているので、、だから絶好調！！（空元気））

"だっちゅうの"　英訳問題 -[omosiro]

だっちゅ～の！ That's it!

「だっちゅうの」を英訳するとき、「だっちゅうの」自体の日本語の意味を正確に理解できないと、正確に英訳できません。

「さっきからそう言ってるでしょ」

と、理解の悪い人にやっと理解させることができたときに、いらだちを ともないながら言うんでしょうか。

だとすれば、お笑いのボケとツッコミの、ツッコミに当たる言葉でしょう。

つまり、真実が1つ決まっていて、そこに追いついたときに、その様子を見て「だっちゅうの」。

では、そういうときに言う（だっちゅうのではない、）正式な日本語ってなんでしょう？

理解の悪い人にあなただったら何て言いますか（捨てゼリフ）？または、自分が理解が悪くて上の人（上司）がいつも言っている言葉は何だったでしょう？

わかった？

「That's it」だっちゅうの！

たぶん、機械翻訳ではなくて英語と日本語が分かっているその道の人が「だっちゅうの！」は「That's it!」と訳したんでしょうね。アクセントも似ているのでうまい翻訳！

（訪問者のどんなニーズと この記事がつながるか）

• 変な話を聞きたい。
• 日記を読みたい。

2020/10/4（日）

自作DRAM回路　問題解決 -[dram]

私は昨年2019年9月から1年あまりのあいだ、趣味で DRAM 回路を自作（電子工作）しています。

なんで DRAM の自作を始めたんだっけ…忘れちゃいました。

プログラミングを自由に行えるようになるためには、できれば ハードウェアの動きを知っていたほうが良い。

そういう目的があるんですが、どんな成り行きで DRAM を始めたのかは忘れました。1年前のその日記を読めばわかりますが…まぁいいか。。

DRAM を電子回路の部品のレベルでその動きを知ったからと言って、直接プログラミングがメキメキ上達するということではありません。

「プログラミングやコンピューターを理解するために、メモリーのしくみを頑張って理解しました」という経験があれば、それが大きな自信やアドバンテージ（有利）になると思うんです。

先月、通販で 10uF のコンデンサを買うはずだったのに間違えて 1uF を買ってしまったので、また買い直しました。

先月末に「自作DRAM回路に疑念がある」と言って、DRAM の記事を一時的に消去しましたが、その疑念は晴れました。

どんな疑念なのかはちょっと説明しづらいので詳しく伝えられませんが、一時、「コンデンサはマイコンへ放電していないのではないか？」と思ってしまったんです。今までメモリーとして書き込みと読み込みができていたのは、マイコンの性質によるもの。つまり、マイコンがピンに対して書き込みを行い、つづいて同じピンに対して読み込みを行うと、ピンの先の回路（コンデンサ）ではなく、マイコンのほうで記憶してあったデータを返すという挙動をする…という疑いを持ってしまったんです。

疑念を晴らすために、コンデンサの放電の様子をオシロスコープで調べました。

※GND は乾電池で言うところのマイナス極だと思えばとりあえず OK です。図はいろいろ省略しています。

PICマイコンに対して書き込んだプログラムは、こんな感じ↓ですが、

多くの人にとっては意味不明のはずなので分かりやすく書き直す（C言語の #define で別名定義する）と、こうなります。↓

プログラムの前半は書き込みを行っていて、後半は読み込みを行っています。

そして実行して PIC マイコンを動かし（値「１」をメモリに書き込む動作）、コンデンサの放電をとらえたオシロスコープの画面は、こうなりました。

下の青い波形が上のプログラムの debug_signal = on; と debug_signal = off; によるものです。

この debug_signal はオシロスコープで波形をとらえるために出す信号であって、DRAM回路には本来 不要なものです。

debug_signal = on; で青の波形が跳ね上がり、debug_signal = off; で青の波形が下がります。

プログラムを見ると、result = pin_input; の直前でこの debug_signal = on; をやっていて、つまり、青の波形が跳ね上がった直後に、マイコンはピンを読んでいるということです。

黄色い波形は壁のように見える前半がマイコンからの 3V 出力（書き込み動作）を行っている波形で、後半がコンデンサからの放電がピンに向かって流れている波形（読み込み動作）です。

青い波形が跳ね上がったときにマイコンはピンを読みます。そのときコンデンサの放電がピンに向かってしっかり行われていないと、「読み損ねる」ことになります。

うまくタイミングを合わせるために、アセンブリ言語で NOP（何もせず、車がアイドリングするようなもの）を入れてマイコンの読み込みをちょっと遅らせています。

下図のようにプログラムと波形の対応を作りました。このようにきちんと正直に対応しているので、まぎれもなくコンデンサの放電をマイコンは受け取っています。ここまで調べて私の疑念は晴れました。

黄色の波形のコンデンサの放電の山の頂上は濃いピンク色に塗りました。

これは PIC24H というマイコンが、放電を「１」として受け取る条件が「2.1V以上」であり、波形がその 2.1V をちゃんと超えているという意味で塗ってあります。

これが下回っていると、マイコンは「１」であると判断できません。

DRAMのプログラムがどうしてもうまく動かないとき、その原因は以上のことからとりあえず２つ考えられます。

• コンデンサの放電とマイコンの読み込みのタイミングがうまくいっていない。
• そもそもコンデンサの放電が「１」となる条件を満たしていない（電圧が低い）。

この２つを確認するためには、オシロスコープが必要になると思いますが、「オシロスコープを用意すること」、「うまく波形をとらえること」、「そして波形の意味を理解すること」は初心者の方には難しいと思います。

DRAM回路を教えるにあたって、この問題をどうしようかなぁと思っているところです。

私は昔はこんなプログラムのハードウェアの世界での動きをとらえて説明するような人じゃなかったんですが、なんか気が付けばこうなっていました。私の努力がそうさせたのか、それとも単に運が良かっただけなのか、どっちかはわかりません。今でも GYAO でやってる「ドラゴンボール超」を観て「いまいちわかんないなー」とか言っているし、ガンプラも買って作ってるし、可愛い絵も描いているし、猫を見かけたら「カワユーイ」なんて思ってちょっかい出すし、その辺は変わりません。

いやいや、ちょっと待て

GYAOでドラゴンボール超　第16話「ベジータが弟子入り!?　ウイスを攻略せよ！」をたった今 観たんだけど、鳥山明じゃない人が作った話のはずだけど、めっちゃおもしろかったぞ…!! ベジータの崩れっぷりが面白い！

DRAMの記事は一応復帰しておきましたが、改めて読んでみると、いくつか不備があって、このままだと同じ電子回路を再現しようとした方がどうやっても出来ないということになるのではと思いました。

電気に詳しい方がこの記事を見たら「？」と思うはずの部分があるので言及しておきます。

コンデンサの充電と放電の波形と言ったら、普通はこうなるはずです。↓

▼充電

▼放電

でも今回「放電」として得られた結果は、↓これでした。

これだとまるで充電しているかのようです。

コンデンサの放電の先がマイコンの入力ピンだとこうなるんでしょうか？

もうちょっと調べる必要がありますね…

2020年10月7日（水）　つづき

それで調べようと思い、

今回のDRAM回路と比較するために、別途「コンデンサ充放電 回路」を作りました。（下図右）

※上図右の薄くしてある部分はあまり関係のない回路です。（薄くしたスイッチ：充電スイッチ、薄くした右下の抵抗：スイッチオフ時のオシロ波形のノイズ除去） この2つの回路はよくみると、ほとんど同じのはずですが 同じ場所の波形をオシロスコープで見ると、下図のように波形が異なっています。なんでだ…
▼DRAM回路の放電波形 （リンクは実験写真）	≠	▼充放電 回路の放電波形 （リンクは実験写真）				▼参考：充放電 回路の充電波形 （リンクは実験写真）

２つの回路の違いは2点あります。

• 放電の受け取りが、マイコンの入力ピンか、LEDか　という違い。
• スイッチが、トランジスタか、手押しスイッチか　という違い。

マイコンのほうでトランジスタを手押しスイッチに替えてみてどうなるか、今度見てみます。（今日はもう時間がないので）

替えてみて もともとのマイコンの波形と同じならば、スイッチの違いは原因ではない とわかります。

（マイコンの中に別にコンデンサが入っていて、”回路の青いコンデンサが電源となり、マイコンの中のコンデンサが充電される。それをオシロで見ている”、ということならその波形になりそう）

2020年10月10日（土）　つづき

コンデンサの放電の波形になるはずなのに充電の波形になっている、という問題で、回路のトランジスタを外して手押しスイッチに替えればスイッチの違いが原因なのかどうかがわかる…ということで、

やってみたんですが、ちょっとうまく波形を見られませんでした。

そこで冷静に回路を考えて、「上の "コンデンサ充放電 回路" の LED を外して、代わりにマイコンの入力ピンをつなげる」という方法を取ってみます。

その回路が下図です。

この回路なら、「トランジスタなしで、放電をマイコンの入力ピンが受け取ったときに、どちらの波形になるか」を確認することができます。

波形が になるなら、この波形（放電のはずなのに充電の波形になっている）はもう「入力ピンのしわざ」ということになると思います。

回路を見て、他に犯人は見当たりませんから。

もし波形が になるなら、トランジスタがあるときだけ この波形になっていた、ということになるので「トランジスタのしわざ」ということになると思います…が、それはないんじゃないかなと思います。やってみないとわかりませんが。。

実行はまた明日。

2020年10月11日（日）　つづき

トランジスタを無しにして、マイコンだけでコンデンサの放電を受け取ってみます。

もし、この波形 になるなら、トランジスタがあるときだけ この波形になっていた、ということがわかります。

▼この回路図を元に、

▼回路を組んで、

▼プログラムも組んで、

▼出てきた波形がこれでした。予想外。

トランジスタがあるときだけ この波形になっていた、ということになるので「トランジスタのしわざ」ということになる、です。

かな？

まだ腑に落ちないので、次は、マイコンなしで手押しでトランジスタをオンにしてみます。

「トランジスタのしわざ」が本当なら、その方法で、 この波形になるはずです。

理論ではなく手探りでやると大変だな…。電気の学生や電気の業界で働いている人にとってはすぐにわかることなんだろうな…。

2020年10月11日（日）　つづき

それで、今度はマイコンを無しにして、トランジスタがある状態でコンデンサの放電を見てみます。

トランジスタが原因でこの波形 になっていた、というのなら、この回路↓で同じ波形が出るはずです。

▼この回路図を元に、

▼回路を組んで、

▼出てきた波形がこれでした。充電？

▼横の時間軸を 1us から 25000 倍の 25ms にするとこんな感じ。縦軸をそのままに横軸をグッと圧縮したので上の波形のカーブ部分が直角になっています。それを考えると…

▼DRAM回路の波形と似てなくもない……同じかな？（理論的に何も言えないのがちょっと残念）

まぁ、つまり、以上のことから、放電になるはずなのに充電の波形になる原因は、マイコンの入力ピンではなく、トランジスタにあるのではないか？

という「しぼりこみ」ができたと思います。

トランジスタが原因ということで、トランジスタの何が原因なのかを、自分なりに考えて見ると、、

• トランジスタの右端のピン（ベースと呼ばれる）に接続している 10kΩ という抵抗値が不適切なのかなぁ……
• トランジスタの中って NPN という並びで P 型と N 型の半導体が並んでいて、真ん中の P 型（トランジスタの右端のピン。ベース）に入ってきた微弱な電流に応じて出力が変わる、ということなので、そのトランジスタのベースへ電流を流しているマイコンのピンの出力のしかたが影響しているか…、それか、トランジスタがスイッチとしてオンになったときこの波形のようにだんだん流れる、とか、そういうことかもしれない…
• ああ、そうだ、そういや、今やってるトランジスタの使い方は「トランジスタの逆接続」になっていて、それが原因かもしれないな…。
  今やっているのはトランジスタの左端のピンにつながっているコンデンサの放電を、トランジスタの真ん中のピンへ流し、その先のマイコンが受け取る、ということですが、それだと、トランジスタのエミッタ（左端ピン）からコレクタ（中央ピン）へ電流を流していて、トランジスタというのは本来コレクタからエミッタへ流すのが本当ということだから逆接続です。逆接続だと、
• 一応トランジスタとして動作することができる。
• しかし、トランジスタの性能として、トランジスタの３つのピンのうち、エミッタ（左端ピン）からコレクタ（中央ピン）のあいだについては流して良い電圧は５Vまで。コレクタ（中央ピン）からエミッタ（左端ピン）だと、３０Vや４０Vなのに。（2N2222という型番のトランジスタの場合）
• トランジスタはベース（右端ピン）に流れてきた電流に応じて出力（コレクタ（中央ピン）からエミッタ（左端ピン））が大きくなりますが、逆接続（エミッタ（左端ピン）からコレクタ（中央ピン））だと、その大きくなる度合いがかなり小さい。
（https://detail-infomation.com/transistor-reverse-connection/より）

コンデンサをつなぐとかではなく、「単純にトランジスタを使ってオンオフするだけの回路」を作ってそれでどんな波形になるか…かな。今度試してみます。

ちなみに、０と１の書き込みと読み込みを繰り返した動画を掲載しておきます。

波形の左側の書き込みの波形は、書き込みと読み込みの間隔を開けたので表示されていません。

とりあえず、この話はこれで終了にします。（DRAM回路の話は続けます）

10月12日(月)　つづき

…終了と言いつつちょっと気になったので調べました。

下図はコンデンサの普通の放電波形だと思いますが、

上図の赤枠で示した部分は、もしかして、画面の横軸を 100ms から 1us くらいにすると、

下図のような形になるんじゃないかなと。

この図は横軸が 1us になっているので、同じような波形になるなら、この図は「放電のはずなのに充電の波形になった。なんで？」ではなく、ふつうに「放電の波形」なんじゃないかと。

というわけで、下図 100ms の画面の赤枠の部分を 1us で表示して見ると…

下図のように、残念ながら（？）直角でした。放電の波形はとにかく直角に放電されるんですね。

やっぱり、この波形はトランジスタが接続されていることが原因で（？）、なぜか充電の動きをしてしまっているみたいです。

10月12日(月)　（同日 第2ラウンド）　つづき

「トランジスタの寄生容量」で検索したところ、次のページが見つかりました。

【トランジスタの寄生容量】コレクタ容量Cobとエミッタ容量Cibとは？

「容量」とはコンデンサのことです。「寄生」とは、人間が意図的にコンデンサ部品を付けてないけど、部品の形状によってコンデンサを付けたのと同じ効果が発生してしまう状態のことです。

トランジスタという部品の形状によって、意図せず、コンデンサの性質が現れてしまうという話です。

このページを読むと、トランジスタには 2pF ～ 3.5pF のコンデンサ成分があるそうです。

私が使っているトランジスタは秋月電子通商の

トランジスタ　２ＳＣ１８１５ＧＲ　６０Ｖ１５０ｍＡ　（２０個入）

です。見つけたページの解説で使っているものと同じトランジスタで、 2pF ～ 3.5pF のコンデンサ成分があるということです。（コレクタ容量）

そのコンデンサ（成分）へ充電している……？

手元にあった 18pF のコンデンサで充電してみると、

その波形はこんな感じでした。

縦軸は 1/2 の 500mV で、横軸は 1us の 1/2 の 500ns となっています。（拡大されているので、実際はもっと小さい波形）

だいぶ見当違いをしている気もするけど、まぁ努力のうちか…

（訪問者のどんなニーズと この記事がつながるか）

• 電子回路の話を聞きたい。
• プログラミングの上達。
• 日記を読みたい。

webappsrcの確認

1. ％％com.webapp.src:/webappsrccheck.html％％
と記述した場合

webapps/src/default.cssのスタイル指定が効く

<!DOCTYPE html><!--ESCAPEPROCESS-->

<head>

<script>

function onloadx() {

//一般関数

console.log( "文字列" );

}

function Class1() {

//クラス

console.log( "文字列" );

}

Class1.prototype.method1 = function() {

//メソッド

console.log( "文字列" );

}

</script>

</head>

<body onload="onloadx();" style="">

Hello world!<BR>

</body>

</html>

---

2. ＜ｃｏｄｅ＞
％％com.webapp.src:/webappsrccheck.html％％
＜／ｃｏｄｅ＞
と記述した場合

このファイルのcodeのスタイル指定が効く

<!DOCTYPE html><!--ESCAPEPROCESS-->

<head>

<script>

function onloadx() {

//一般関数

console.log( "文字列" );

}

function Class1() {

//クラス

console.log( "文字列" );

}

Class1.prototype.method1 = function() {

//メソッド

console.log( "文字列" );

}

</script>

</head>

<body onload="onloadx();" style="">

Hello world!<BR>

</body>

</html>

---

3.
％％com.webapp.src:/webappsrccheck2.html,/webappsrccheck.html％％
と記述した場合

webapps/src/default.cssのスタイル指定が効く

<!DOCTYPE html><!--ESCAPEPROCESS-->

<head>

<script>

function onloadx() {

//一般関数　コメント変更

console.log( "文字列変更" );

行追加

}

function Class1() {

//クラス　コメント変更

console.log( "文字列変更" );

行追加

}

Class1.prototype.method1 = function() {

//メソッド　コメント変更

console.log( "文字列変更" );

行追加

}

</script>

</head>

<body onload="onloadx();文字列変更" style="">

Hello world!<BR>

HTML追加

</body>

</html>

---

4. ＜ｃｏｄｅ＞
％％com.webapp.src:/webappsrccheck2.html,/webappsrccheck.html％％＜／ｃｏｄｅ＞
と記述した場合

このファイルのcodeのスタイル指定が効く

<!DOCTYPE html><!--ESCAPEPROCESS-->

<head>

<script>

function onloadx() {

//一般関数　コメント変更

console.log( "文字列変更" );

行追加

}

function Class1() {

//クラス　コメント変更

console.log( "文字列変更" );

行追加

}

Class1.prototype.method1 = function() {

//メソッド　コメント変更

console.log( "文字列変更" );

行追加

}

</script>

</head>

<body onload="onloadx();文字列変更" style="">

Hello world!<BR>

HTML追加

</body>

</html>

---

5. リンクで
src?webappsrccheck.html
と記述した場合

webapps/src/default.cssのスタイル指定が効く
開く

---

6. リンクで
src?webappsrccheck2.html,webappsrccheck.html
と記述した場合

webapps/src/default.cssのスタイル指定が効く
開く